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Amendments to the drawings, 

There are no amendments to the Drawings, 
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Remarks 

Status of application 

Claims 1-43 were examined and stand rejected in view of prior art. The claims 
have been amended to further clarify Applicant's invention. Reexamination and 
reconsideration are respectfully requested. 

The invention 

A database system with methodology for automated determination and selection 
of optimal indexes is described, In one embodiment, for example, in a database system 
having an optimizer for generating an access plan for processing a given database query^ 
an optimizer-based method of the present invention is described for recommending 
database indexes to be created for optimizing system perfomiance, the method comprises 
steps of: capturing a workload representative of database queries employed during system 
use; based on indexes sought by the optimizer during generation of access plans for the 
database queries, creating virtual indexes for optimizing system performance during 
execution of the database queries captured in the workload, wherein each the virtual 
index comprises an in-memory data structure corresponding to a set of potential physical 
indexes; computing cost benefits for different combinations of the virtual indexes by rc- 
optimizing the workload multiple times, each time cluninating Icss-bcncficial indexes 
from consideration; and recommending physical indexes to be created based on virtual 
indexes thai have favorable cost beneiils for the captured workload. 

A. Section 102 rejection: Lcnzic 

Claims 1-43 are rejected under 35 U.S.C. 102(e) as being anticipated by Lenzie 
("Lenzie" US Patent 6,728,720), The Examiner's rejection ofclaim I is representative: 

As per claim 1, Lenzie teaches *'a method for recommending 
database indexes lo be created for optimizing system performance^ the 
method comprising:" (see Abstract) 

"capturing a workload representative of database queries employed 

II 
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dxiring system use;*' (column 5 lines 17-22, wherein a copy is made of all 
the SQL queries supplied to the engine over a selected period of time) 

"creating virtual indexes for optimizing system performance during 
execution of the database queries captured in the workload;" (column 5 
lines 22-28 and column 8 lines 8-13, wherein an index optimizer creates a 
set ofprelerred indexes for a dambase) 

"computing cost benefits for different combinations of the virtual 
indexes;" (column 9 lines 24-40, wherein the cost of indexes arc 
calculated) 

"and recommending physical indexes to be created based on virtual 
indexes thai have favorable cost benefits for the captured workload." 
(colxmm 12 lines 53-59, wherein an index with the higjicst cost saving is 
selected). 

For the reasons stated below, Applicant's claimed invention may be distinguished on a 
variety of grounds. 

Prior art solutions, including Lenzie, use each virtual index to represent a single 
possible physical index — ihai is, virtual indexes in prior an systems have a one-io-one 
relationship to physical indexes. Applicant's Index Consultant invention, in contrast, uses 
an optimizer-based approach where each virtual index to represent a set or class of 
potential physical indexes. As discussed below, how virtual indexes are created in 
Applicant's system and what they look like once created dilTers substantially from prior 
art approaches. 

Consider the basic prior art approach, such as typified by Lcnzic. The prior art 
index optimization system receives a query and then immediately proceeds to extract or 
parse the interesting pieces (e.g., the predicates and "order by" constructs) by looking at 
the text of the query. Lcnzic and similar systems have a separate algorithm that creates 
virtual indexes based on the syntax of the queries and the capabilities of the optimizer 
when the algorithm was wrhtcn. Based on this preprocessing, the prior art system builds 
up different virtual indexes that may or may not be helpful to the optimizer. 

Tn Applicant's Index Consultant, the approach is very dilTerenl: Applicant's 

12 
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system builds the original set of virtual indexes based on the optimizer's needs. The 
query is not parsed up front but is instead passed on to the database engine's optimizer 
(i.e., the query is allowed to be processed in a normal manner by the optimizer). 
Spccificaliyj the optimizer is "watched" for what indexes it needs during 
"preoptimization" phase. As the optimizer goes through its nonnal process of deciding 
whai access plan to build for the query, the optimizer will check for the presence of 
certain indexes. Applicant's Index Consultant docs not examine the syntax of the queries 
in order to create the initial set of vutual mdcxcs but instead lets the optimizer opthnizc 
the workload and "watches" it for what types of uidexes it is looking for. 

Applicant's Index Consultant uses the optimizer check (i.e*, whether a particular 
index exists) to build up virtual indexes, where each virtual index itself represents an 
ontirc set or class of potential physical indexes. This approach provides Important 
advantages. Because the optimizer is only mtcrcstcd in general characteristics of an 
index. Applicant's invention can construct a virtual index that has a more general 
deliniiion ihan ones created by prior art systems. In Applicant's system, a single virtual 
index also includes the "don^t care" cases, thus representing a whole class of potential 
physical indexes. As such, Applicanf s Index Consultant is the only solution that 
represents a virtual index as a set of poieniial physical indexes. For example, the viriual 
index {A "don't care", B "don't eare"} represents the following set of 8 physical indexes: 

(A ASC, B ASC ), (A DESC, B DESC ), (A ASC, B DESC ), (A DESC, B ASC ), 
(B ASC, A ASC ), (B DESC, A DESC ), (B ASC, A DESC ), ( B DESC, A ASC ) 

Prior art solutions, including Lcnzic, create each of these 8 indexes as separate virtual 
indexes. A "virtual index" in Applicant's system represents a whole set of physical 
indexes, not just a single physical index. This allows, for example, Applicant's system to 
use a single virtual index structure to represent dozens of physical indexes^ instead of the 
prior art approach of using a single virtual index to represent a single physical index (i.e., 
1 : 1 relationship). The main advantage of this representation is that Applicant's Index 
Consultant works with a very compact set of virtual indexes and leaves its choices open 
until the end of the process. As the optimizer (in a database system using Applicant's 

13 
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approach;) proceeds through its normal optimization, Applicant's Index Consultant may 
become more specific about what the final physical index might look like, 

AppHcanrs optimizer-based approach has other advantages. Any modifications 
made in the optimizer do not affect the Index Consultant. For example, if the optimizer is 
modified to support a new join method that may make use of a certain type of index, the 
Index Consultant does not have to be modified or even know about the new join method. 
Applicant's Index Consultant will sec the need for a certain index when the optimizer is 
looking for it. it will not know -or care - what the index itself will be used for. Another 
example is the recommendation of indexes for materialized views that are not referenced 
in the query text but can be used by the optimizer to answer part of a query. Applicant's 
Index Consultant will see that the opUmizer is looking for an index for a table V which is 
in fact a materialized view- candidate. No other solutions or tools can handle 
recommendation of indexes for tables which arc not referenced in the original workload. 

As another advantage. Applicant's Index Consultant collapses its candidate virtual 
indexes at the end of the process. Given ihe general represeniaiion of a virtual index, the 
collapsing is very efficient. Additionally, Applicant's Index Consultant is unique in the 
way the original space requirements are taken into accoimt by dropping 20% (at a time) 
of Ihe less-useful virtual indexes. The Index Consultant is the only solution available thai 
"reoptimizes" the workload more than twice to discard indexes made not useful by the 
dropping of the 20% of the indexes. 

Applicant's independent claims 1 and 24 have been amended to bring these 
distinctions to the forelront. For example, the preamble of claim 1 has been amended to 
emphasize that the claimed method is an optimizer-based approach, as follows (shown in 
amended form): 

1 . (Currently amended) In a database system having an optimizer 
for generating an access plan for processing a given database query , a an^ 
optimizcr^bascd method for recommending database indexes to be created 
for optimizing system performance, [...] 

Additionally, claim I have been amended to emphasize that the virtual indexes 

14 
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are created based on the processing of the optimizer, and that the virtual indexes 
themselves correspond to sets of potential physical indexes: 

l?ascd Qft iindc?cqs sought by feg Pptimigcr dwing gcugration pf 
accci^s plans fqy s^jj^ femb^^c queries, creating virtual indexes for 
optimizing system performance during execution of the database queries 
captured in the workloa d, wherein each said virtual index com prises an in- 
mcmory data structure corresponding to a set of potential physical 
indgxg?; 

The feature of Applicant's Index Consultant that "rcoplimizes" the workload multiple 
times to discard Icss-bcncficial indexes (e.g., by dropping of the 20% of the less-useful 
indexes) is set forth in the amended claim limitation: 

computing cosi. beneltts for dilTerent combinations of the virtual 
indexes by rc-optimizing the workload multiple times, each time * * 

eliminating less-beneficial indexes from consideration : 

(Applicant's other independent claim, claim 24, has been amended in a similar fashion.) 
It is respectfully submitted that the amended claims set forth a patentable advance over 
the art. 

All told. Applicant's Index Consultant invention constructs virtual indexes in a 
unique and advantageous manner. This results from the fact that Applicant's approach 
involves watching the optimizer, as opposed to the prior art approach of simply looking 
at the syntax of a query. Unless one adopts; an approach thai requires that the optimizer 
be watched, one cannot create a system that creates a virtual index comprising a set of 
physical indexes in the manner done by Applicant's system (and required by Applicant's 
amended claims). In other words, if the optimizer is not watched, then one cannot 
discern or know the set of indexes tha-t are available for the optimizer to use. Therefore, 
at the core architectural level, Applicant's optimizer-based approach is very different 
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from Lenzie and other prior art solutions. As Lenzie teaches an approach that occurs 
entirely outside of (i.e., irrespective of) the optimizer, the Lenzie teaches, if anything, 
away Irom Applicani's claimed approach. In view of the above-discussed amendments 
and clariiying remarks^ it is respectfully submitted that the rejection under Section 102 is 



Any dependent claims not explicitly discussed arc believed to be allowable by 
virtue of dependency from Applicant's independent claims, as discussed in detail above. 

Conclusion 

Tn view of the foregoing remarks and the amendment to the claims, it is beh'eved 
that all claims arc now in condition for allowance. Hcnco» it is respectfully requested that 
the application be passed to issue at an early date. 

If for any reason the Examiner feels that a telephone conference would in any way 
expedite prosecution ofihe subject application, the Examiner is invited lo telephone the 
undersigned at 408 884 1507. 



overcome. 



RespecifuUy submitted, 



Date: October 26, 2006 




John A. Smart; Reg. No. 34,929 
Attorney of Record 



408 m 1507 

HI 5 572 g299KAX 
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